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TECHNICAL FIELD 

This invention relates to console-based gaming systems, and more 
particularly, to methods for establishing secure communications between two 
gaming systems connected via a local area network. 

5 

6 BACKGROUND 

Traditionally, gaming systems with a dedicated console were standalone 
machines that accommodated a limited number of players (e.g., 2-4 players). 
9 Personal computer-based gaming grew in popularity in part due to the ability to 
il io play games online with many remote players over the Internet. Thus, one trend for 
dedicated gaming systems is to provide capabilities to facilitate gaming over a 
12 network, such Internet-based online gaming and LAN-based gaming where 
B multiple consoles are connected through a local area network (LAN). 
14 One challenge in network gaming is to protect network traffic between any 

is two game consoles from tampering or observation by other devices on the 

16 network. Gamers are notorious for developing creative cheating mechanisms. For 

17 example, gamers have used computers to display portions of a game map which 
is would otherwise not be visible, or modified unprotected network traffic to give 

19 themselves advantages during play, such as perfect aim, faster players, and so on. 

20 Unfortunately, previous console-based gaming systems did not provide for secure 

21 communications. 

22 Accordingly, there is a need for a system architecture that supports secure 

23 communications between two or more gaming systems over a local area network. 
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SUMMARY 

A network architecture for console based gaming systems is described. The 
architecture allows multiple game consoles to establish secure communication 
over a local area network. 

In the described implementation, the system architecture supports a three- 
phase secure communication protocol. The first phase involves generating shared 
keys that are unique to an authentic game console running an authentic game title. 
The same game consoles running the same games will create the same shared 
keys. In the second phase, a "client" console attempts to discover existing game 
sessions being hosted by a "host" game console by broadcasting a request over the 
local area network. The broadcast request expresses a desire to join in playing the 
game at the next convenient opportunity. The broadcast request is protected using 
the shared keys. If the host console agrees to let the client console play, the host 
console generates session keys that are returned securely to the client console. 
The third phase involves a key exchange in which the client and host consoles 
exchange data used to derive one or more secrets. The key exchange is protected 
using the session keys. The secrets are then used to establish a secure point-to- 
point link between the two consoles for ongoing communication. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 illustrates a gaming system with a game console and one or more 
controllers. 

Fig. 2 is a block diagram of the gaming system. 

Fig. 3 illustrates a network gaming system in which the Fig. 1 gaming 
system is connected via a local area network to other gaming systems. 
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Fig. 4 illustrates a first phase of a secure communication process in which a 
game console running an authentic game title generates shared secret keys. 

Fig. 5 illustrates a second phase of the secure communication process in 
which a client game console discovers a host game console on the local area 
network. 

Fig. 6 illustrates a third phase of the secure communication process in 
which the client and host game consoles establish a point-to-point communication 
link. 

DETAILED DESCRIPTION 

The following discussion is directed to console-based gaming systems and 
techniques for establishing secure communications between multiple gaming 
systems connected via a local area network (LAN). The discussion assumes that 
the reader is familiar with basic cryptography principles, such as encryption, 
decryption, authentication, hashing, and digital signatures. For a basic 
introduction to cryptography, the reader is directed to a text written by Bruce 
Schneier and entitled, "Applied Cryptography: Protocols, Algorithms, and Source 
Code in C," published by John Wiley & Sons, copyright 1994 (second edition 
1996), which is hereby incorporated by reference. 

Gaming System 

Fig. 1 shows an exemplary gaming system 100. It includes a game console 
102 and up to four controllers, as represented by controllers 104(1) and 104(2). 
The game console 102 is equipped with an internal hard disk drive and a portable 
media drive 106. The portable media drive 106 supports various forms of portable 
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12 



storage media as represented by optical storage disc 108. Examples of suitable 
2 portable storage media include DVD, CD-ROM, game discs, game cartridges, and 
so forth. 

The game console 102 has four slots 110 on its front face to support up to 

5 four controllers, although the number and arrangement of slots may be modified. 

6 A power button 1 12 and an eject button 1 14 are also positioned on the front face 
of the game console 102. The power button 112 switches power to the game 
console and the eject button 1 14 alternately opens and closes a tray of the portable 
media drive 106 to allow insertion and extraction of the storage disc 108. 

io The game console 102 connects to a television or other display (not shown) 

i i via A/V interfacing cables 120. A power cable 122 provides power to the game 
console. The game console 102 may further be equipped with internal or 

13 externally added network capabilities, as represented by the cable or modem 

14 connector 124 to facilitate access to a network, such as a local area network 
is (LAN) or the Internet. 

16 Each controller 104 is coupled to the game console 102 via a wire or 

i? wireless interface. In the illustrated implementation, the controllers are USB 
is (Universal Serial Bus) compatible and are connected to the console 102 via serial 

19 cables 130. The controller 102 may be equipped with any of a wide variety of 

20 user interaction mechanisms. As illustrated in Fig. 1, each controller 104 is 

21 equipped with two thumbsticks 132(1) and 132(2), a D-pad 134, buttons 136, and 

22 two triggers 138. These mechanisms are merely representative, and other known 

23 gaming mechanisms may be substituted for or added to those shown in Fig. 1. 

24 A memory unit (MU) 140 may be inserted into the controller 104 to 

25 provide additional and portable storage. Portable memory units enable users to 
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store game parameters and transport them for play on other consoles. In the 
described implementation, each controller is configured to accommodate two 
memory units 140, although more or less than two units may be employed in other 
implementations. 

The gaming system 100 is capable of playing, for example, games, music, 
and videos. With the different storage offerings, titles can be played from the hard 
disk drive or the portable medium 108 in drive 106, from an online source, or from 
a memory unit 140. A sample of what the gaming system 100 is capable of 
playing back includes: 

1. Game titles played from CD and DVD discs, from the hard disk drive, 
or from an online source. 

2. Digital music played from a CD in the portable media drive 106, from a 
compressed file on the hard disk drive (e.g., Windows Media Audio 
(WMA) format), or from online streaming sources. 

3. Digital audio/video played from a DVD disc in the portable media drive 
106, from a file on the hard disk drive (e.g., Windows Media Video 
(WMV) format), or from online streaming sources. 

Fig. 2 shows functional components of the gaming system 100 in more 
detail. The game console 102 has a central processing unit (CPU) 200 and a 
memory controller 202 that facilitates processor access to various types of 
memory, including a flash ROM (Read Only Memory) 204, a RAM (Random 
Access Memory) 206, a hard disk drive 208, and the portable media drive 106. 
The CPU 200 is equipped with a level 1 cache 210 and a level 2 cache 212 to 
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temporarily store data and hence reduce the number of memory access cycles, 
thereby improving processing speed and throughput. 

The CPU 200, memory controller 202, and various memory devices are 
interconnected via one or more buses, including serial and parallel buses, a 
memory bus, a peripheral bus, and a processor or local bus using any of a variety 
of bus architectures. By way of example, such architectures can include an 
Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) 
bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association 
(VESA) local bus, and a Peripheral Component Interconnect (PCI) bus. 

As one suitable implementation, the CPU 200, memory controller 202, 
ROM 204, and RAM 206 are integrated onto a common module 214. In this 
implementation, ROM 204 is configured as a flash ROM that is connected to the 
memory controller 202 via a PCI (Peripheral Component Interconnect) bus and a 
ROM bus (neither of which are shown). RAM 206 is configured as multiple DDR 
SDRAM (Double Data Rate Synchronous Dynamic RAM) modules that are 
independently controlled by the memory controller 202 via separate buses (not 
shown). The hard disk drive 208 and portable media drive 106 are connected to 
the memory controller via the PCI bus and an ATA (AT Attachment) bus 216. 

A 3D graphics processing unit 220 and a video encoder 222 form a video 
processing pipeline for high speed and high resolution graphics processing. Data 
is carried from the graphics processing unit 220 to the video encoder 222 via a 
digital video bus (not shown). An audio processing unit 224 and an audio codec 
(coder/decoder) 226 form a corresponding audio processing pipeline with high 
fidelity and stereo processing. Audio data is carried between the audio processing 
unit 224 and the audio codec 226 via a communication link (not shown). The 
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video and audio processing pipelines output data to an A/V (audio/video) port 228 
for transmission to the television or other display. In the illustrated 
implementation, the video and audio processing components 220-228 are mounted 
on the module 214. 

Also implemented on the module 214 are a USB host controller 230 and a 
network interface 232. The USB host controller 230 is coupled to the CPU 200 
and the memory controller 202 via a bus (e.g., PCI bus) and serves as host for the 
peripheral controllers 104(1)- 104(4). The network interface 232 provides access 
to a network (e.g., LAN, Internet, etc.) and may be any of a wide variety of 
various wired or wireless interface components including an Ethernet card, a 
modem, a Bluetooth module, a cable modem, and the like. 

The game console 102 has two dual controller support subassemblies 
240(1) and 240(2), with each subassembly supporting two game controllers 
104(1)- 104(4). A front panel I/O subassembly 242 supports the functionality of 
the power button 1 12 and the eject button 1 14, as well as any LEDs (light emitting 
diodes) or other indicators exposed on the outer surface of the game console. The 
subassemblies 240(1), 240(2), and 242 are coupled to the module 214 via one or 
more cable assemblies 244. 

Eight memory units 140(1)-140(8) are illustrated as being connectable to 
the four controllers 104(1)- 104(4), i.e., two memory units for each controller. 
Each memory unit 140 offers additional storage on which games, game 
parameters, and other data may be stored. When inserted into a controller, the 
memory unit 140 can be accessed by the memory controller 202. 
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A system power supply module 250 provides power to the components of 
the gaming system 100. A fan 252 cools the circuitry within the game console 
102. 

A console user interface (UI) application 260 is stored on the hard disk 
drive 208. When the game console is powered on, various portions of the console 
application 260 are loaded into RAM 206 and/or caches 210, 212 and executed on 
the CPU 200. The console application 260 presents a graphical user interface that 
provides a consistent user experience when navigating to different media types 
available on the game console. 

The game console 102 implements a cryptography engine to perform 
common cryptographic functions, such as encryption, decryption, authentication, 
digital signing, hashing, and the like. The cryptography engine may be 
implemented as part of the CPU 200, or in software stored in memory (e.g., ROM 
204, hard disk drive 208) that executes on the CPU, so that the CPU is configured 
to perform the cryptographic functions. 

The gaming system 100 may be operated as a standalone system by simply 
connecting the system to a television or other display. In this standalone mode, 
the gaming system 100 allows one or more players to play games, watch movies, 
or listen to music. However, with the integration of network connectivity made 
available through the network interface 232, the gaming system 100 may further 
be operated as a participant in a larger network gaming community. This network 
gaming environment is described next. 
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Network Gaming 

Fig. 3 shows an exemplary network gaming environment 300 in which 
multiple gaming systems 100(1), 100(2),..., 100(g) are interconnected via a local 
area network 302. LAN 302 may be implemented using any one or more of a 
wide variety of conventional communications media including both wired and 
wireless media. As one example, the LAN 302 represents an Ethernet cross-over 
cable or an Ethernet hub. Other possible implementations of LAN 302 include 
Fire Wire (specifically, IEEE 1394) and universal serial bus (USB). 

Many game titles are scalable to support multiple players on different 
consoles. Interconnecting multiple gaming systems via the LAN 302 enables 
multiple players to compete in the same game. For example, some game titles 
allow up to 16 different players, which can be composed of any combination of 
players and gaming systems (e.g., from one player each on 16 gaming systems to 
four players each on four gaming systems). 

A network-based game is hosted by one of the game consoles. For 
discussion purposes, suppose that gaming system 100(1) hosts the game for client 
gaming systems 100(2), 100(g). In this context, the hosting function is one of 
coordinating player access to the multiplayer game. The "hosting" metaphor is 
not meant to imply that one game console serves the game content to other game 
consoles. Each game console 100 has its own copy of the game stored either on 
the hard disk drive 208 (e.g., purchased and downloaded an authentic game title 
from a vendor's website) or the portable storage medium as represented by a 
digital video disk (DVD) 108(1), 108(2), 108(g). 



Iee@hayes pjic 509-324-9256 



9 



J 1 1 20 J J 200 MS1-890US PA TAPP DOC 



Secure Communication Protocol 

All game consoles involved in a network gaming situation initially establish 
secure communication links between one another. Secure communications means 
that data can be transferred between two entities in a manner that is resistant to 
tampering. The transferred data can be authenticated by the entities to ensure that 
a trusted entity did indeed send that particular data. Secure communications may 
or may not involve encryption, which effectively renders the transmitted data blind 
to an observer. If encryption is used, it may occur before or after authentication. 

With reference to Fig. 3, each client game console 100(2)-(g) that wants to 
participate seeks permission from the host gaming system 100(1). If the host is 
willing, secure communications are established between the requesting client 
console and the host console. Establishment of a secure communications link is 
accomplished by a three phase process. Briefly, the first phase involves 
generation of shared secret keys that only an authentic game console running an 
authentic game title will know. The second phase concerns session discovery in 
which a client console attempts to discover existing game sessions being hosted by 
a host game console. During session discovery, the client console broadcasts a 
discovery request over the local area network. The discovery request expresses a 
desire to join the LAN-based game at the next convenient opportunity. The 
discovery request is protected using the shared keys. If the host console agrees to 
let the client console play, the host console generates a discovery reply containing 
session keys. The discovery reply is returned to the client console via broadcast, 
directly, or indirectly. The third phase involves a key exchange in which the client 
and host consoles exchange data used to derive one or more secrets. The key 
exchange is protected using the session keys. The secrets are then used to 
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establish a secure point-to-point link between the multiple consoles for ongoing 
communication. 

These phases will be described below in more detail according to one 
possible implementation of the secure communication protocol. 

Phase I: Generate Shared Secret Kevs 

Fig. 4 shows the first phase 400 of the secure communication protocol in 
which a shared secret key that is unique to an authentic gaming system running an 
authentic game title is generated. The console stores a secret key 402 in a secure 
location, such as in a protected portion of ROM 204. Additionally, each game title 
certified to play on the gaming system has an associated unique, randomly- 
generated title key 404. The title key 404 is the same for every copy of the same 
game title. Different titles have different title keys. The title key 404 may be 
stored as part of the game title, such as on the DVD or with a softcopy of the game 
title that was legitimately purchased online and downloaded for storage on the 
hard disk drive of the game console. 

A LAN key generator 406 uses the console-based key 402 and the title- 
based key 404 to derive a LAN key 408. In one implementation, the LAN key 
generator 406 computes a one-way cryptographic function using the two keys 402 
and 404 during a network stack initialization. As one example of a suitable 
cryptographic function, the LAN key generator 406 concatenates the keys 402 and 
404 and performs an HMAC-SHA-1 (Hashed Message Authentication Code- 
Secure Hash Algorithm 1) operation on them to produce the LAN key 408. 

The LAN key 408 is then used to produce shared secret keys. More 
particularly, when the network stack is initialized, a broadcast key generator 410 
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uses the LAN key 408 to generate a title broadcast encryption key 412 and a title 
broadcast signature key 414. As one example, the generator 410 may create keys 
for symmetric ciphers, asymmetric ciphers, hashing algorithms, and digest 
algorithms. 

Generation of the broadcast keys 412 and 414 is performed once during 
initialization. All gaming systems running the same title will generate the same 
pair of keys. Any gaming system running a different title on the same LAN will 
have a different pair of keys. The combination of keys prevents anyone from 
discovering how to intercept or modify broadcast messages for a particular game 
simply by being able to read the game title. 

Phase II: Session Discovery 

Fig. 5 shows the second phase 500 of the secure communication protocol in 
which a client console attempts to discover whether any other consoles on the 
LAN are currently hosting a multiplayer game session of a particular title. With 
only a few consoles connected on a small local area network, there is not expected 
to be more than one or two consoles currently hosting a particular game. With 
small numbers of consoles, there is no third-party matchmaking service and hence 
the client console is left to discover suitable hosts on its own through a broadcast 
technique. It is noted, however, that in the future the number of available game 
sessions might be quite large and a dedicated matchmaking service may be used to 
find a suitable match. 

The second phase is described in the context of a general flow of operations 
performed by a requesting client console 100(2) and a potential host console 
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100(1). The operations are illustrated beneath the client and host consoles to 
convey where such operations are performed. 

At operation 502, the client console 100(2) generates a request REQ 
containing a request message and an optional nonce Nj (the initiator's nonce). At 
operation 504, the client console encrypts the request using a symmetric key 
cipher E (e.g., DES) that employs the title broadcast encryption key 412 (denoted 
as K E ), as follows: 

REQ = EKE[request message, NJ. 

At operation 506, the client console digitally signs the request using the 
title broadcast signature key 414 (denoted as K s ), as follows: 

REQ ES = Sks[REQ e ]. 

At operation 508, the client console broadcasts the encrypted and signed 
request REQ ES to other consoles on the LAN 302. The host console 100(1) has 
previously opened a UDP (User Datagram Protocol) socket and is listening for 
discovery broadcast messages over the LAN. Consoles running the same game 
title will recognize the request because they are able to generate the same set of 
title broadcast keys 412 and 414, and hence can authenticate and decrypt the 
message. Consoles running different game titles, however, will disregard the 
message. Assume that one host console exists and is running the same game title 
(operation 510). Accordingly, the host console is likewise able to derive the title 
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1 broadcast encryption key 412 and the title broadcast signature key 414 as provided 

2 in phase I (Fig. 4). 

3 At operation 512, the host console authenticates the request using the same 

4 title broadcast signature key 414. At operation 514, the host console decrypts the 

5 message using the same title broadcast encryption key 412, as follows: 

6 

7 REQ = D KE [REQ E ]. 

a 8 

J| 9 At operation 516, the host console decides whether to allow the requesting 

i = 3 " 

client console to participate in the network game. Factors affecting this decision 
include the number of current players, number of players supported by the game, 

i2 current status of the game (i.e., just beginning, middle of session, etc.), and so on. 

u" 13 Assuming that the host console will accept a new client console with one or more 

Gj H players, the host console generates a unique pair of keys used to distinguish 

is between different sessions (operation 518). These keys include a network key 

16 identifier NKID and a network key exchange key NKEY. The identifier NKID is 

17 simply a name for the key NKEY. In one implementation, the session keys are 
is created by a random number generator. These keys are used in the key exchange 

19 phase described below with reference to Fig. 6. The session key NKEY will be 

20 used in the future to authenticate the contents of key exchange packets exchanged 

21 between the two consoles, whereas the key identifier NKID is used to specify the 

22 game session to which the source console is connecting. It is noted that the 

23 session keys NKID and NKEY may be pre-generated prior to receiving any 

24 request from a client console. 



25 
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At operation 520, the host console creates a reply to the discovery request. 
The reply contains, at a minimum, a reply message, the NKID / NKEY pair, and a 
network address NADDR of the host game console. The reply message may 
include the initiator's nonce Ni, a responded s nonce Nr, and game specific data. 
At operation 522, the host console encrypts the reply usingpthe title broadcast 
encryption key 412, as follows: 

REPLY E = E KE [reply message, NKID, NKEY, NADDR]. 

At operation 524, the client console signs the reply using the title broadcast 
signature key 414 (denoted as K s ), as follows: 



REPLY ES = S KS [REPLY E ]. 



At operation 526, the host console broadcasts the reply across the local area 
network 302 to other consoles, including the requesting client console 100(2). At 
operation 528, the client console authenticates and decrypts the reply. Every host 
console responds with its own encrypted broadcast reply containing the network 
address, as well as an encryption key and identifier specific to that game session. 
Having discovered one or more hosts available on the network, the client 
communicates with the desired host using session key pair of that host. Any other 
session key pairs returned by other potential hosts are discarded. 
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Phase III: Key Exchange 

Fig. 6 shows the third phase 600 of the secure communication protocol in 
which the client and host perform a secure key exchange to establish a secure 
point-to-point link for ongoing communication. After game session discovery, the 
client and host consoles share a title broadcast encryption key 412 and a title 
broadcast signature key 414, as well as a session key pair NKID/NKEY for a 
particular game session. Now, the client and host consoles exchange data used to 
derive one or more keys that are used to secure point-to-point communication. In 
the described implementation, the consoles use Diffie-Hellman exponentiation 
operations to derive a new secret that is shared between the two consoles without 
transmitting that secret across the LAN. The key exchange is protected using the 
session key. 

For the discussion purposes, suppose the client console is the initiator of the 
key exchange and the host is the responder. When the client sends the first packet, 
the client notices that there is no security association established between the game 
client and game host. The packet is placed on a packet queue and the key 
exchange process is started. 

At operation 602, the client creates an initial key exchange packet 
KeyExInit The packet includes secrets used to derive symmetric keys used to 
secure communication in a point-to-point communication link. As one exemplary 
implementation, the key exchange packet is a UDP packet with a payload 
containing the following data: 

Data Field Definition 

Noncelnit This field contains a random nonce created by the 
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initiator. It is used to validate replies and compute 
keys. 



NonceResp 



g 



NKID 



NADDR 



Time 



Hash 



This field contains a random nonce created by the 
responder. It is used to validate replies and 
compute keys. 

This field contains the Diffie-Hellman 
exponentiation provided by the initiator. 

This field specifies the key identifier that identifies 
the game session key and that both consoles have 
by virtue of the second phase session discovery. 

This field contains the complete network address 
information of the sender of the message. 

This field contains a time value that is used to limit 
replay attacks. Every time a key exchange packet 
it transmitted (or retransmitted for timeouts), this 
value is incremented by one unit and that time is 
transmitted in the key exchange packet. Should 
the initiator or responder reboot and attempt to 
rejoin the same game session (because it 
reacquired the same NKID / NKEY pair from the 
game host via broadcast when it came back up), its 
system time will have moved forward by many 
thousands if not millions of units. The purpose of 
this scheme is to prevent the replay of key 
exchange initiator packets disrupting the security 
association between a pair of consoles. 

This field contains a hash digest of the key 
exchange packet. 



At operation 604, the client console computes a hash digest of the entire 
message using the session key NKEY and a hashing function H, as follows: 



Hashlnit - H NKE y [Noncelnit, g x , NKID, NADDR, Time]. 
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Accordingly, creation of the initial key exchange packet KeyExInit 
involves generating a random nonce "Noncelnit", filling in the computed Diffie- 
Hellman value "g x ", filling in the NKID and NADDR fields, and incrementing 
and setting the "Time" field. All other fields are zeroed. The hash digest of all 
preceding fields ("Hashlnit") is placed in the "Hash" field of the key exchange 
packet so that the packet can be authenticated by the receiving console (e.g., host 
console). The resulting packet is as follows: 

KeyExInit: [Noncelnit, g x , NKID, NADDR, Time, Hashlnit]. 

At operation 606, the client console sends the initial key exchange packet 
KeyExInit to the host console. When this message is received, the host console 
uses the key identifier in the NKID field to identify the key NKEY of the 
particular game session. The session key is then used to authenticate the message 
as originating from the client console (operation 608). More particularly, the host 
uses the session key NKEY to compute a hash digest of the contents and compare 
that digest to the attached "Hashlnit" value received in the initial key exchange 
packet. 

At operation 610, the host console creates a responsive key exchange 
packet (denoted as "KeyExResp"). In the continuing example, the host console 
generates a random nonce "NonceResp", fills in its computed value from the 
Diffie-Hellman function g Y , fills in the NKID and NADDR fields, and increments 
and sets the "Time" field. The "Noncelnit" field is copied from the initial 
message. 
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At operation 612, the host console hashes the response packet using the 
session key NKEY, as follows: 

HashResp = H NKEy [Noncelnit, NonceResp, g Y , NKID, NADDR, Time]. 

The hash digest is placed in the "Hash" field of the key exchange packet. 
The response packet now has the following contents: 

KeyExResp: [Noncelnit, NonceResp, g Y , NKID, NADDR, Time, 
HashResp]. 

At operation 614, the host console sends the response key exchange packet 
KeyExResp to the client console. Upon receipt, the client console uses the key 
identifier in the NKID field to identify the session key NKEY. The session key 
NKEY is then used to authenticate the message as originating from the host 
console (operation 616). That is, the client uses the session key NKEY to compute 
a hash digest of the response packet and compare that digest to the attached 
"HashResp" value received in the response packet. 

At this point, both the host and the client have enough data to compute 
security association keys (operation 618). Security association keys are used to 
secure point-to-point communication between two consoles. In this example, each 
console uses the two Diffie-Hellman exponentiations to compute function g^. 
Each console can then compute four different digests using Noncelnit, 
NonceResp, and g^ as input, as well as the session key NKEY. These digests are 
used to form the security association keys. 
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Once the client has the security association keys, it is free to transmit any 
packets that have been waiting for key exchange to complete. The host console, 
however, is not free to do so even though it has the same set of keys because it 
cannot be sure that its response message KeyExResp was not lost. The host waits 
until it either receives a KeyExAck message or until it receives a packet 
authenticated with the computed security association key (operation 620). 

In the common case, the client console sends a packet to the host and thus, 
the key exchange process consists of just two messages— KeyExInit and 
KeyExResp. Should the client not have a packet to send, it will send an artificial 
acknowledge message (denoted as "KeyExAck"). This message differs from the 
two other key exchange messages in that the message is hashed using the 
computed security association key instead of the session key NKEY. 

From this point forward, the two consoles use the security association keys 
to secure communications. All network packets that need to be transmitted to the 
other consoles are authenticated after optionally being encrypted, with the 
receiving console verifying the authentication data before decrypting the packet 
contents. Once a game session is finished, either console can stop accepting key- 
exchange requests from any console using this session key pair NKID/NKEY. 
The duration of the session keys is expected to be anywhere from a few minutes to 
a few hours. 

Conclusion 

Although the invention has been described in language specific to structural 
features and/or methodological acts, it is to be understood that the invention 
defined in the appended claims is not necessarily limited to the specific features or 
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i ii acts described. Rather, the specific features and acts are disclosed as exemplary 
2 II forms of implementing the claimed invention. 
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